When either of these 2 things happen, maybe your best talent starts to leave the organisation. Maybe your product fails to create change for its customers and you stop growing/start shrinking. Maybe your org decides that this ‘Agile’ thing isn’t really for them and moves back to Waterfall.
Agile fails because its our belief that it is a software delivery methodology.
So how can we make Agile create successful change
Notice some subtlety there?
Create successful change
Agile is not about delivering software. It isn’t a methodology with a rule book that we can follow in order to push my products forwards.
Instead — Agile is a Philosophy about enabling positive customer change that drives business value.
Lets start by recapping the core values of the Agile Manifesto:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Lets break this down and look at each individual section:
Individuals and interactions over processes and tools
In Agile — we need to value our individuals and the interactions over our processes and tools that we’ve brought in. I’ve written before about this and it’s been my most successful Medium article so far:
Your tools are not the problem, your reliance on them is.uxdesign.cc
We also need to stop our processes holding us back too. Just because what we’re doing isn’t strictly by a book someone has on their desk — it doesn’t mean we shouldn’t try it to see if it works for us. I say this a lot but:
Every business is different and every team in every business is different. One size doesn’t fit all.
Working software over comprehensive documentation
This value means we focus on deliver actual working software out to our users vs creating humungous documentation.
This doesn’t mean that we don’t document — which is how some teams see it.
Instead we document what we’re doing and what we have learnt, whilst maintaining a focus be on actually shipping beneficial change out to our user base. I shouldn’t need to produce 50 pages on the ‘what’ we are embarking on building before I start to understand how it affects our users.
The second part to the working software part of this value is that we need to focus on the fact that it ‘works’. And this is in 2 elements:
1 – Users can do what they need to do in it
Is it usable, does it act and behave in a way that users expect it to?
2- Its relatively bug free that users can complete their tasks with it
Are users able to do what they need to do without any hinderance?
Customer collaboration over contract negotiation
Your users are important. There’s quite possibly a million+ articles on Medium alone about why you should listen to your users and build your Products based off what they’re telling you.
You need to work with your users to understand that you’re building the right thing for them. This isn’t Field of Dreams.
Just because you build something doesn’t meant they’ll use it.
If you build the right thing for your users — ultimately the change you deliver will have more positive outcomes for your business.
Ultimately who is paying your wages? Your users — so listen to them.
Responding to change over following a plan
We’ve all seen this diagram:
This is often used to indicate that we should learn as we build and I whole-heartedly agree with that — but what a lot of people don’t consider is that maybe we should have stopped at the bicycle.
If our goal was to enable people to get from A to B, perhaps the bicycle is the best possible method. Maybe we’d love to have a car but right now its not the thing we should be spending the time on. Maybe building the engine adds another £500k to the build cost and thats just not viable right now.
In the Agile manifesto we respond to change by paying attention to whats happening with our Products and how our users are interacting with them.
This value in the manifesto is not used as a get out clause for stakeholders to constantly change direction on you — no matter what some might think.
Building a culture around agility
The first and foremost important thing about building a culture around agility is for us to stop thinking about delivering software with it.
We need to focus on delivering beneficial change to our users.
There isn’t a perfect way to do Agile. I must have worked with 30+ teams in my career and every single one of them has done Agile in a different way — and thats absolutely fine.
But if you follow these steps — you can start to create more agility for your customer outcomes.
1: Create individual interactions within your team
Use the standups, planning sessions and retrospectives as a opportunity to actual discuss how you’re doing against your goals as a team of people.
Focus on building your team vs it being a group of people working in a similar area. Christina Wodtke has just given a great talk on this at Mind the Product: https://www.mindtheproduct.com/2018/07/reboot-your-team-by-christina-wodtke/
2. Start figuring out how to build up autonomy and trust for your team
Start acting as a single unit towards an outcome. Report on how you’re doing against that outcome and align your outcomes towards company goals.
If the most important thing for your company right now is to stop customer churn, communicate on how your changes are affecting that.
If you’re having a positive impact — you will win trust and autonomy to keep doing a good job.
If you’re not having a positive impact — it forces the question about what it is you’re focusing on and why. This is good and again will win trust for the team.
3. Involve your users frequently
Encourage your whole team to go sit in the contact centre and listen to calls. Get them to dive into your UX research tools and read the customer statements. Invite them along to guerrilla user testing in your local cafe. Everyone should be involved with seeing their users of their products interact with them.
There’s a big movement out at the moment to create ‘user fridays’ where every Friday users are brought in and the team works with them. This is an idealistic view and its great if you can do it — but start small with the resources you have. The main point i’m making here is that its not just up to one person on the team to understand how the changes the team are producing are affecting the users.
4. Communicate, communicate and communicate
Sharing is caring. Always talk about what you’re doing and why you’re doing it, both internally within the team and externally:
Internally within the team
Communicate on what it is you’re focusing on and why at the moment. If we need to focus on the conversion rate within our checkout — why are we doing that?
Communicate to the team why fixing that bit of tech debt just doesn’t quite make sense right now.
Communicate on whats working and not working for the team — has someone done a stellar job this week and needs recognition.
Communicate on what affect the changes the team have worked on have done to the user base.
Externally to the business
Communicate on what you’ve been working on and why you’ve been workong in it.
If the team had to spend 5 days ironing our trunk problems after a branch merge — communicate on that.
Maybe you had to down tools for a sprint just to clean the bugs up in your backlog as it had got unruly.
Most importantly — communicate on the positive impact that your changes have driven along with the ones that delivered no value. When you communicate on the ones that didn’t behave as expected — tell people what you’ve learn from it.
5. Build learning and experimentation with your methods into your Agile process.
Agile encourages us to constantly learn — but we should also be actively encouraged to experiment with how we are going about things. Sometimes we’ll bring something in and it won’t work — but other times what we suggest will massively benefit how we’re doing thing.
6. Finally — Focus on delivering change and not software.
Measure your success on the outcome that your changes are having for your customers and not on the dates you ship out your software.
The org won’t care that you delivered something on the 1st of March if it did nothing to improve your offering for your customers.
By starting to follow these 6 tips you’ll slowly but firmly start to actually act more Agile. It’ll take time, but keep investment in your practices. If you ever reach ‘nirvana’ — start asking yourself bigger questions. There’s always room for improvement.